ShareWare OnLine 2/ShareWare OnLine Volume 2 (CMS Software)(1993).iso/games1/fsstruct.zip/FSSTRUCT.TXT

Text File | 1992-11-04 | 85KB | 1,826 lines

                         MICROSOFT FLIGHT SIMULATOR
                            DATA FILE STRUCTURES

INTRODUCTION

Document version 2.0, release date: 15 November 1992.
Updates:
∙ Added static scenery record codes reference
∙ Completed 5Ah record in mountain description
∙ Corrected description of 0Bh, 0Eh, 16h, 25h records and "range" records
∙ Added ATC records and many records used in other kinds of scenery
∙ Added .DEM and .MOD file structures
Many record codes have been added, and more obscure points have surfaced.

Document version 1.0, release date: 15 September 1992.

This document describes the structures of files created or provided with
Microsoft Flight Simulator 4.0 and/or the Microsof Aircraft and Scenery
Designer ver 1. The document is ideally addressed to developers and requires
a good knowledge of hex notation and some familiarity with programmingconcepts.


Conventions:
∙ The symbol "m" always means meters, while nautical miles are noted by "NM".
∙ Hex values are marked with an final 'h', non-marked values are decimal, the
  only exception being code dumps in examples which are in hex.
∙ Within scenery files, all multi-byte values follow the Intel convention:  lower order bytes precede higher order bytes; they are often transcribed as
  a single value restoring the correct digit positions ("53h 07h" means a
  byte value 53h followed by a byte value 07h, while "FFFBh" means a word
  value FFFBh made of a first byte FBh and a second byte FFh).
∙ Record structure is given in columnar form: in the 1st column the offset
  within the record, in the 2nd the length of each field, in the 3rd the
  description of the field.
∙ Unindentified or undeciphered (parts of) records are marked with "???".∙ Records fields which have the same value xxxx in all the examples I saw are
  described as "always xxxx ??".
∙ Fields whose value, when arbitrarely changed by hand, does not affect
  object appearance or behaviour are declared "irrelevant".

Additions, corrections or suggestions are welcome. I apologize for English
language errors and inelegancies.
I would like express my debt to Greg Pierson [72520,1775] whose program
DCOD01.EXE has been seminal in my work and to Dan Samuel [70110,434] who
contributed a lot of information.

                    Maurizio M. Gavioli

          CompuServe: 100021,2335
          InterNet:   "Maurizio M. Gavioli" <[e-mail]>

--------------------------
DISCLAIMER
--------------------------

The below information was derived from hours of analysis of FS4/ASD files
(often manually generated for this very purpose).  The FS4/ASD community as awhole has spent way too much time decoding this information in order to
generate useful utilities.  It would be nice if the original authors chose to
publish an "official" documentation of FS data files.  However, the below
information is not distributed with an eye towards enabling anyone to rob the
original authors of any rightful profits and should be used only for the
common good of the FS4 community and to encourage availability and sales of
FS4 and related products and utilities.
========================================

                              GENERAL CONCEPTS

FS COORDINATES AND GEOGRAPHIC UNIT

FS North and East coordinates are internally coded with code 49,152 (= C000h)
representing coordinate 0; therefore codes from 49,152 to 65,535 (C000h toFFFFh) represent coordinates from 0 to 16,383 and codes from 0 to 49,151
(0000h to BFFFh) represent coordinates from 16,384 to 65,535. The reason for
this coordinate shift is not clear.

Within programs, internally coded coordinates can be convert to external FS
coordinated by subtracting 49152 (C000h) from the value considered as
unsigned
Manually, coded coordinates below 49,152 can be converted to FS coordinates
by adding 16,384, and coded coordinates above 49,151 can be converted by
subtracting 49152.

Judging from how scenery radii are converted to Km by ASD, 1 FS coordinate
unit (FSu) seems to be very close to 256 meters.

Coded coordinates can appear in object definitions in one of three ways:
∙ INTEGER (2 bytes): a word containing only an integer coordinate (indicated
as "int FSu")

∙ FRACTIONARY (4 bytes): a double word made of a high order word (4th and 3rd
bytes) containing the coordinate integer part and a low order word (2nd and
1st bytes) containing the fractionary part.  In most cases, the 1st byte is
0: the fractionary part is therefore expressed in 256th, and each 256th isalmost equal to 1 meter.  Therefore, fractionary coordinates can also be
interpreted as made by 3 high order bytes expressing a distance (from
coordinate origin) in meters and a low order byte containing a fractionary
part in 256th of meter; this is confirmed by altitude fields, because
altitude is almost invariably indicated in this way (with the fractionary
byte left often unfilled). Both interpretations are indicated as "fract FSu".

∙ DELTA (2 bytes): a word representing the difference from an actualcoordinate given elsewhere (usually in a previous ref. point record, see
below); the high order byte (2nd byte) contains the integer part of the
difference and the low order byte (1st byte) the fractionary part; as
fractionary part units are equal to 1 meter, delta coords can also be
interpreted as distance in meters from the reference point. Contrarily to the
other two representations, which are always positive, this representation is
signed, and therefore the maximum possible difference (and the maximum
possible radius of a scenery object) is 32,767 m. This representation isindicated as "delta FSu".


OBJECT ORIENTATION

Some objects, like runways, buildings and aircraft positions, are oriented.
The angle of this orientation is always given relatively to the North axis of
the FS coordinate system. For some kind of cartographic compensation notdiscussed here, this axis is not necessarily the same as the compass North
(this explains why, while flying or slewing in the 0.00 direction, E
coordinate also can slowly change). Directions displayed by FS and ASD are
relative to the compass North and, therefore, there can be a rotation between
the directions as displayed by ASD and as memorized in the files.

Unless otherwise stated, orientation or heading fields, as well as "pitch"
and "bank" fields, are 2 bytes long and are expressed in 1/182.04°: 0000h =0°  ->  10000h = 360°


RECORDS

Many kinds of FS data files are made of "records", i.e. chunks whose
structure, contents and meaning are determined by the first record byte
(thereafter called "record code"); records may contain many values(thereafter called "fields"), and, with a few exceptions, the length of the
record is constant for each record code. Records appear in the files one
after the other; given the start point and the structure (or at least the
length) corresponding to each record code, a file can be sequentially parsed
and decoded.

Record code meanings may change (and usually do) from a file type to another.
Some file types (as .SC1 and .DY1) start with a non-record coded portion("header") containing general information about the file.


VARIABLES

FS apparently mantains somewhere in memory a set of variables, which affect
the display engine and/or the flight simulation engine.  These variables are
accessed with a value which looks like a memory address (or a table offset)and has been called "variable address". Attested addresses are in the range
0288h - 031Eh.  Variables can be set and tested from within a scenery file.

Attested variable usages are the following:

var at    set to         in

0288      0001           fuel boxes028C                     2 = day; 4 = night; 6 = dusk?
029C                     East plane position?
029E                     Alt. plane position?
02A0                     North plane position?
02E2      colour         surfaces; the colour code is usually repeated in all
                         the four nibbles
02EF      altit. (in m)  to set the altitude above sea level of current area
02F6      0001           inner marker02F8      0001           outer markers
02FA      0001           middle markers
0312      0001           by SEE, before 20h, 1Fh record list
031E      0000           mountains
031E      0001               "


BYTE OFFSET
Many records contain an offset, pointing to another record. It is used to
state the total length of an object definition (or of a relevant portion of
it) or to provide some forms of inter-record addressing for conditional
(after variable test) or unconditional jumps.  These offsets are indicates as
"bytes offset" and are always relative to first byte (code byte) of the
record which contains them.

======================================================================

                         STATIC SCENERY FILES (.SC1)

GENERAL STRUCTURE

Static scenery files are made of:
∙ a header containing a lookup table for the various file sections, the
  scenery boundaries, and the scenery name; this header is 73 bytes long;

∙ 9 sections, containing definitions of Navaids, Polygon, Rivers, Roads,
  Lines, Runways, Mountains, Timing gates, and Buildings respectively.  Each
  section is terminated by a single byte code 79h. Consequently, an empty
  scenery file is 82 bytes long: 73 for the header and 1 for the ending byte  of each section.

Each object definition is made by records describing the different features
or parts of the object; the great majority of the records have a fixed
length, but objects of variable shape (like polygons) may contain a variable
number of records and have therefore a variable length.

In static scenery files, some record codes can have the most significant bitset or reset, without any apparent difference.  Attested cases are always
reported.

====================

HEADER STRUCTURE - length: 73 bytes

0         2    file size2         2    0003h (a kind of signature?)
4         2    002Ah (= 42, pointer to scenery name)
6         2    0049h (= 73, header length)
8         2    pointer to Navaid section (always 73)
10        2    pointer to Polygon section
12        2    pointer to River section
14        2    pointer to Road section
16        2    pointer to Line section18        2    pointer to Runway section
20        2    pointer to Mountain section
22        2    pointer to Timing gate section
24        2    pointer to Building section
26        4    E coord. of scenery center (fract. FSu: all 4 bytes used)
30        4    N coord. of scenery center (fract. FSu: all 4 bytes used)
34        2    scenery radius (int. FSu)
36        6    always 0 ??42        31   scenery names: up to 30 characters (padded with space, if
               shorter) plus a 0 ending byte


====================

                            RECORD CODE REFERENCE
Record are listed by code.  Field at offset 0 always contains the record code
and is 1 byte long.

Some records are not found in .SC1 files, but have been detected in other
kind of sceneries and have been included for completness (?); usually their
meaning is unknown, only their length has been determined.

Records found in SEE enhanced sceneries are marked with SEE, while recordsfound in the default scenery F1 are marked DEF.  These kinds of scenery have
not been completely parsed yet, therefore it cannot be excluded that a record
appears in other scenery kind as well.

Record description contributed by Dan Samuel are marked with an DS.


-- 00h ------DS----- ??? (7 bytes) =SEE=

-- 01h ------DS----- ??? (7 bytes) =SEE=

-- 02h ------DS----- ??? (7 bytes) =SEE=

-- 03h ------DS----- ??? (2 bytes) =SEE=
-- 05h ------------- NDB (11 bytes)

1         2    frequency; BCD coded (ex.: 327 kHZ -> 27h 03h)
3         4    E coord. (fract. FSu)
7         4    N coord. (fract. FSu)

-- 0Bh ------DS----- Unconditional jump (3/5 bytes)
1         2    byte offset
[3        2    signature?]

This record tells FS to jump over a given amount of bytes, avoiding rendering
some object feature. It is usually used after a test record to providing
branching to another point fo the object definition.

This record is very problematic: it is probably only 3 bytes long, but it isalso sometime used to insert in the file some information (a 2-byte
"signature" is a common case) apparently not relevant for the display engine
but in some way useful to the scenery editor (either ASD or SEE or whatever)
for identifying the object been defined.  See also the discussion under
record 0Eh.

-- 0E/8Eh ---DS----- Jump over 0Bh record (3 bytes)
1         2    byte offset

This record has a meaning quite similar to 0Bh, but it is attested only for
jumping above a 0Bh record.  The length at offset 1 is either 0006h or 0008h,
for 0Bh records 3 or 5 bytes long resp.

Records 0Eh and 0Bh are often used within many object definitions in a
particular construct:
0         1    0Eh: record code
1         2    0006h (when there is no "signature") or 0008h (when there is a
               "signature")
3         1    0Bh: record code
4         2    lenght
[6        2    "signature" corresponding to the type of the object being
               defined]
The given length is the length of the remainder of the object definition or
of a part of it; this length, added to the offset of the 0Bh record code
byte, points to a single byte 19h record.

This construct has been cumulatively called "variable structure construct"
and the 19h record "end of variable structure record".
-- 0Fh ------------- ?? (6 bytes) =DEF=

-- 12h ------------- Line Colour (2 bytes)

1         1    colour code from the following table:

               0         Black
               1         Dark Green               2         Dark Blue
               3         Dark Cyan
               4         Orange
               5         Light Grey
               6         Light Blue
               7         Cyan
               8         Brown
               9         Yellow               Ah        Dark Grey
               Bh        Light Green
               Ch        Red
               Dh        Gold
               Eh        (apparently not used/transparent?)
               Fh        White

-- 13h ------------- ?? (15 bytes) =DEF=
-- 14h ------------- ?? (10 bytes) =SCN=

-- 15h ------DS----- Orientation/delta point (16 bytes) =SEE=

1         2    "pitch" ?
3         2    "bank" ?
5         2    heading7         2    E coord. (delta FSu)
9         2    A coord. (delta FSu)
11        2    N coord. (delta FSu)
13        2    always 0010h ??
15        1    always 19h ??

-- 16h ------------- Orientation (9 bytes)
0         1    16h: record code
1         2    "pitch" (noze down is positive, noze up is negative)
3         2    "bank" (left is positive, right is negative)
5         2    orientation or heading
7         2    always 000A ??

"Pitch" and "bank" come from an airplane analogy and describe object tilting
as if it were an airplane.  Orientation is relative to the North coordinateaxis, not to the compass North.

-- 17h ------------- ?? (1 byte)

This single byte record has been observed only in timing gate definitions.

-- 18h ------------- ?? (3 bytes) =DEF=
-- 19h ------------- End of structure (1 byte)

This record, made of the single byte 19h, marks the end of a variable
structure contruct (0Eh + 0Bh).

-- 1Ah ------------- ?? (5 bytes) =DEF=

-- 1Dh ------------- VOR (11 bytes)
1         2    frequency; BCD coded (ex.: 109.15 MHz -> 15h 09h)
3         4    E coord. (fract. FSu)
7         4    N coord. (fract. FSu)

-- 1Eh xxxx -------- ATC message (xxxx bytes)

1         2    record length3         2    frequency; BCD coded (ex.: 127.15 MHz -> 15h 27h)
5         4    4 runway numbers (often repeated)
9         4    fixed: 1Eh 37h 52h 3Ch
13        var  message text (0-terminated)

The message text can include any character from ASCII 20h to ASCII 93h.
Characters greater than 93h result in garbage being transmitted. When the
message is played back, characters from 80h to 93h are expanded into thefollowing strings (stored in ATC.FS4):

80h       " Whether - "
81h       " OBSERVATION "
82h       " XX:00 ZULU " (where XX is replaced by the current hour time)
83h       "" (empty string)
84h       " TEMPERATURE 25 - "
85h       " INFORMATION "86h       " LANDING AND DEPARTING RUNWAY XX - " (where XX is replaced by the
          runway number given at offset 5)
87h       " ADVISE CONTROLLER "
88h       " ALTIMETER 29.95 - "
89h       " VISIBILITY 10 - "
8Ah       " WIND XXX at YY - " (where XXX and YY are replaced by wind
          direction and speed defined by the wind menu or generated by the
          weather generator; if both are off, this character is ignored)8Bh       " MEASURED CEILING 00600 OVERCAST "
8Ch       "" (empty string)
8Dh       "" (empty string)
8Eh       "Microsoft Flight Simulator"
8Fh       " requesting "
90h       "clearance "
91h       ", your are cleared "
92h       "... "93h       "7777 "

-- 1Fh ------DS----- Branch (3 bytes)

1         2    byte offset

A group of 1F records is generally preceded by a 20h record.
-- 20h ------DS----- Jump if var between (9 bytes)

1         2    byte offset
3         2    address of variable
5         2    value1
7         2    value2

This record jumps over the given amount of bytes, if variable at the givenaddress tests some way in relation to value1 and value2.  value2 is often
7FFFh and the test can be: "branch if var is between value1 and value2".

-- 21h ------------- Check 2 vars for range (15 bytes)

1         2    byte offset
3         2    var1 address
5         2    var1 min value7         2    var1 max value
9         2    var2 address
11        2    var2 min value
13        2    var2 max offset

This record, as well as the following, is either:

∙ oriented toward the display engine and skips over (or steps through) agroup of records when the two given variables are outside or inside the given
ranges or
∙ oriented toward the flight simulator engine and performs (or doesn't
perform) some task when...

The record has been found, among other, in fuel boxes (which are aways
displayed), where variables are 029Ch and 02A0h and ranges cover the fuel box
surface; one may speculate that these variables, during the simulation, holdthe plane E and N coordinates (029Eh containing the altitude) and that
refueling occurs when the plane is inside the fuel box surface.

This record is widely used in F1, where var1 is often equal to var2.

-- 22h ------------- Check 3 vars for range (21 bytes)

1         2    byte offset3         2    var1 address
5         2    var1 min value
7         2    var1 max value
9         2    var2 address
11        2    var2 min value
13        2    var2 max offset
15        2    var3 address
17        2    var3 min value19        2    var3 max offset

This record is similar to the previous, but involves 3 variables.

It has been found in mountain definitions, where vars are 029Ch, 029Eh, 02A0h
and ranges include the mountain volume.

-- 23h ------DS----- Jump if var not equal (7 bytes)
1         2    byte offset
3         2    var address
5         2    value

This record jumps if the given var is not equal to the given value.

-- 24h ------------- Reference point (14 bytes)
1         1    always 04h ??
2         4    E coord. (fract. FSu)
6         4    AGL alt. (fract. FSu)
10        4    N coord. (fract. FSu)

A reference point record is used within the definitions of some kinds of
object to define a point in 3D, near the center of the object; other pointsof the object are then defined relatively to this point.

-- 25h ------DS----- Set variable (5 bytes)

1         2    variable address
3         2    new variable value

This record sets the given variable to the given value.
-- 28 -------------- ?? record (8 bytes)

1         1    record sub-code?? (always 36h in .SC1)
2         2    byte offset ?
4         2    var address ?
6         2    value ?
Used in suspended bridges, cars and fuel boxes.  Attested in F1.

-- 29h ------------- Close path (1 byte)

This record, made of the single byte 29h, is used to close a path being drawn
with 40h and 41h records.  A line is drawn from the current point to the
starting point of the last executed 41h record.  If the surface colour
variable (02E2h) has been set, the path is filled with that colour.
It is not clear how the display engine is able to detect when the colour var
has not been set (var 02E2h will always contain some value), maybe the line
colour record (line drawing is the only occasion when surface filling is not
required) sets the colour var to a null (0Eh ?) or invalid colour code.

-- 2Ah ------DS----- Two delta points (14 bytes) =SEE=
1         2    P1 E coord. (delta FSu)
3         2    P1 A coord. (delta FSu)
5         2    P1 N coord. (delta FSu)
7         2    P2 E coord. (delta FSu)
9         2    P2 A coord. (delta FSu)
11        2    P2 N coord. (delta FSu)
13        1    ??
-- 2Fh ------------- Path list begin (1 byte)

This record, made of the single byte 2Fh, is used to start a path.  Path are
used to draw lines and polygon perimeters.

The path list describes a path made of straight lines connecting points. Each
path description begins with the single byte code 2Fh.  Then, a move record
defines the first path point and other draw or move records define the otherpoints.

Line paths can contain any combination of move and draw operations to
describe interrupted lines. Polygon perimeters have a move to the first point
followed by draws to following points.

Paths can be 'closed' by a single byte record 29h which draws a line from the
current point to the starting point of last move record.  Polygon perimetersMUST be closed.

-- 30h ------------- ?? (8 bytes) =DEF=

-- 31h ------------- 3D-point (8 bytes)

1         1    point number (for mountains, peaks are numbered from 01h to
               0Fh, base points from 21h inward)2         2    E coord of point (delta FSu)
4         2    Altitude in m above ground level
6         2    N coord of point (delta FSu)

This record is used in mountain description to set mountain vertices.

-- 32h ------DS----- Move to 3D point (2 bytes) =SEE=
1         1    point number

Moves the pen (without drawing) to the point.  Point numbers have been set by
a previous 31h record.

-- 33h ------DS----- Draw to 3D point (2 bytes) =SEE=

1         1    point number
Draws to the point.  Point numbers have been set by a previous 31h record.

-- 35h ------DS----- ?? (2 bytes) =SEE=

-- 3Eh ------------- Area (9 bytes)

1         2    byte offset: the total length in bytes of the following object               definition (this record included)
3         2    N coord. (int FSu)
5         2    E coord. (int FSu)
7         2    area radius (int FSu)

An area record starts the representation of each scenery object, gives the
total length of the object and defines the area (usually centered near the
object center) within which the object is visible.
-- 40/C0h ---------- Move to 2D point (5 bytes)
-- 41h ------------- Draw to 2D point (5 bytes)

1         2    E coord. of the point (delta FSu)
3         2    N coord. of the point (delta FSu)

Move and draw records are used to define points of lines and of polygonperimeters.  A move record moves to the point given in the record without
drawing anything, a draw record draws a line segment or a polygon boundary
from the previous point to the given point.  Move record code can be either
40h or C0h, without any visible difference.

All coords are delta coords and are relative to a previously given ref. point
record.
-- 43h ------DS----- ?? (1 byte)

-- 45h xxxx -------- Thermal generator (xxxx bytes)

1         2    record length (0025h)
3         4    E coord of generator center (fract FSu)
7         4    altitude AGL of generator center ?
11        4    N coord of generator center (fract FSu)15        2    orientation
17        1    ???
18        2    generator width (in m)
20        2    ???
22        2    thermal effect height (in feet)
24        2    ???
26        2    generator length (in m)
28        9    ???
This record has been found only in thermal generators.

-- 4Ch ------DS----- ?? (2 bytes) =SEE=

-- 4Dh xxxx--DS----- ?? (xxxx bytes) =SEE=

-- 4Eh ------DS----- ?? (4 bytes) =SEE=
-- 4Fh ------------- ILS (15 bytes)

1         2    frequency; BCD coded (ex.: 109.15 MHz -> 15h 09h)
3         4    E coord. (fract. FSu)
7         4    N coord. (fract. FSu)
11        2    Approach course in 1/3° (0 -> 0, 359 -> 0435h)
13        3    Glide slope in 1/9100 (0 -> 0, 7.20 -> FFFFh)
-- 50/D0h ---------- Runway (35 bytes)

See below under runway descriptions for details.

-- 51h ------------- Side list end (used in mountains, 1 byte)

-- 52h ------DS----- ?? (2 bytes) =SEE=
-- 53h ------------- Building (variable)

The building record defines the aspect of a building, its length and
structure varies according to the building type. Here a summary is given, see
below, under building descriptions, for details.

2nd byte                 building type and length
01             Rectangular building record (18 [flat] and 19 [peaked] bytes)
02             L building record (24 [flat] and 27 [peaked] bytes)
03             T building record (28 [flat] and 32 [peaked] bytes)
04             U building record (28 [flat] and 33 [peaked] bytes)
05             H building record (34 [flat] and 41 [peaked] bytes)
06             Reversed L build. record (24 [flat] and 27 [peaked] bytes)
07             Control tower record (20 bytes)29             Tower record (6 bytes)
33             Suspended bridge record (8 bytes)
34             Bridge record (8 bytes)
3D             Timing gate record (17 bytes)
42             Coniferous tree record (7 bytes)
43             Deciduous tree record (7 bytes)
47             Auto record (3 bytes)
4C             Multi-sided building record (13 bytes)
-- 58h ------DS----- 3D text (43 bytes) =SEE=

1         7    ???
8         2    text size
10        32   text, 0-terminated
42        1    always 17h ?? (in that case, it could be another occurrence of
               the 17h record)
-- 5Ah ------DS----- 3D-triangle (10 bytes)

1         2    E component of the "triangle vector" (see below)
3         2    A component
5         2    N component
7         3    numbers of the 3 points, listed in anti-clockwise order
               looking to the triangle from outside
This record is used in mountains and is probably used to speed up the hidden
surface removing process.  The "triangle vector" is the cross product of the
vectors for the P2-P1 and the P3-P1 edges of the tiangle, the cross product
is then scaled so that no coord value is > 16383.  Point numbers at offset 7-
9 correspond to mountain vertices defines in a previous list of 3D points
(list of 31h records).
-- 6Fh ------DS----- ?? (11 bytes) =SEE=

-- 79h ------------- Linked list end (1 byte)

Marks end of linked list. It is used to mark the end of .SC1 file sections.


====================
          OBJECT DETAILED DESCRIPTIONS

The following section contains a detailed description of all the object found
in standard .SC1 files, with examples of decoding.  With the exception of ATC
messages, SEE extensions are not included.

====================
NAV AIDS

Like all .SC1 object, navaids begin with an area record; NDB, VOR, and ILS
add a specific record (05h, 1Dh, 4Fh, resp.); Markers add a 25h record
setting var 02F6h (inner marker), 02F8h (outer marker) or 02FAh (middle
marker) to 0001.
Adding the 9 bytes of the area record, the total length of each kind of Nav
aids is (in parenthesis, the area radius set by ASD):

NDB       20 bytes       (500 FSu = 128 Km = 69 NM)
VOR       20 bytes       (500 FSu = 128 Km = 69 NM)
ILS       24 bytes       (250 FSu = 64 Km = 34.6 NM)
OM        14 bytes       (2 FSu = 512 m)
MM        14 bytes       (2 FSu = 512 m)IM        14 bytes       (1 FSu = 256 m)

Example:

3E 18 00 92 03 8C 04 FA 00 4F 25 09 00 06 8C 04 00 00 92 03 2C 01 FF 6A

is interpreted as:
3Eh       Area record
  0018h        object is 24 bytes long
  0392h        N coord of visib. area is [0392h =] 914 + 16384 = 17298
  048Ch        E coord of visib. area is [048Ch =] 1164 + 16384 = 17548
  00FA         area radius is [FAh =] 500 FSu
4Fh       ILS record
  0925h        frequency is 109.25 MHz
  048C0600h    E coord is [0485.06h =] 1164+6/256 + 16384 = 17548.0234  03920000h    N coord is [0392.00h =]  914+0/256 + 16384 = 17298.0000
  012Ch        approach course is [012Ch =] 300 / 3 = 100°
  6AFFh        glide slope is [6AFFh = ] 27391 / 9100 = 3.01

====================

ATC MESSAGES
ASD cannot add ATC messages to sceneries. However, messages added to .SC1
files with other programs (or manually!) are correctly played by FS4 and do
not interfere with ASD ability to manipulate the modified .SC1.
The following structure has been determined from SEE4-modified sceneries.

ATC messages are made by:
∙ an area record
∙ a 5-byte jump record with fixed contents: 0Bh 0005h 41h 43h (where 4341h isprobably an ID meaning "ATC")
∙ an ATC message record (1Eh)

====================

POLYGONS

Polygon descriptions are made of an area record, a ref. point record, asurface colour record and a point list.  As for any object of variable size,
area radius is not fixed, like in nav aids, but depends on the polygon size.

Triangles are special, because, after the polygon proper, they add a 3-point
line corresponding to two of the three sides of the triangle; this line has
the same colour of the triangle and cannot be seen.

Example:
3E 3E 00 92 03 8D 04 03 00 24 04 00 4D 8D 04 00
0A 00 00 00 B9 92 03 25 E2 02 99 99 2F 40 F2 FF
08 00 41 0D 00 0B 00 41 0F 00 F6 FF 29 12 09 40
F2 FF 08 00 41 0D 00 0B 00 41 0F 00 F6 FF

is interpreted as:
3Eh       Area record
  003Eh        object is 62 bytes long
  0392h        N coord of visib. area is 17298
  048Dh        E coord of visib. area is 17549
  0003         area radius is 3 FSu
24h 04h   Ref. point record
  048D4D00h    E coord is [048D.4Dh =] 1165+77/256 + 16384 = 17549.0273
  00000A00h    altitude above ground level is [00000Ah =] 10 m  0392B900h    N coord is [0392.B9h =] 914+185/256 + 16384 = 17298.7227
25h       Set variable record
  02E2h        variable at 02E2 (surface colour)
  9999h        set to colour 9 (yellow)
2Fh       Point list begin
40h       Move record
  FFF2h        E coord of P1: [FF.F2h =] -14/256 + 17549.0273 = 17548.9726
  0008h        N coord of P1: [00.08h =]   8/256 + 17298.7227 = 17298.754041h       Draw record
  000Dh        E coord of P2: [00.0Dh =]  13/256 + 17549.0273 = 17549.0781
  000Bh        N coord of P2: [00.0Bh =]  11/256 + 17298.7227 = 17298.7657
41h       Draw record
  000Fh        E coord of P3: [00.0Fh =]  15/256 + 17549.0273 = 17549.0859
  FFF6h        N coord of P3: [FF.F6h =] -10/256 + 17298.7227 = 17298.6836
29h       Close and fill (polygons with 4 or more points, would stop there)
12h 09h   Line colour is 9 (yellow)40h FFF2h 0008h same move record as above
41h 000Dh 000Bh same draw record as above
41h 000Fh FFF6h same draw record as above

====================

RIVERS
Even if they are created in ASD stretching and bending rectangular strips of
colour, rivers are actually memorized in scenery files as polygons, and
follow the same format described in the previous section. The reason for
keeping them in a specific section resides probably in the order in which
scenery object are drawn.

Rivers can also contain skips: in this case, the river description contains a
single area record and a single ref. point record followed by a surfacecolour record and a point list for each polygon created by skipping.

====================

ROADS

Roads also are memorized as polygons, and follow the polygon format. For
skippings, the same observation made about rivers, holds also for roads.
Country roads and city streets require no observations.

4-lane roads contain, after the point list describing the road perimeter, a
line colour record and a line point list describing the road middle line.

Divided highways, after the area and ref. point records, contain a single
surface colour record (25h) with two polygon point lists to describe the tworoad ways, then a line colour record, a conditional jump record (23h) on var
028Ch value and another line colour record to change colour line according to
time, and a line point list with 4 jumps to describe the 4 borders of the
ways.

====================

LINES
Line descriptions are made of an area record, a ref. point record, a line
colour record and a line point list.  If the line contains skips, a new line
colour record and a new line point list are generated for each line section.

====================

RUNWAYS
Runway descriptions are made of 2 area records referring to the same point
(one for the distance at which the runway is sketchily visible, the other for
the distance at which it is fully visible), a 25h record to set area altitude
and the specialized runway record:

Runway record - code: 50h/D0h  length: 35 bytes
0         1    50h or D0h: record code
1         4    E coord of center (fract. FSu)
5         4    Altitude (fract. FSu)
9         4    N coord of center (fract. FSu)
13        1    Design elements (bit is 1 if the element is present):
               bit       7: always 1
                         6: always 1
                         5: Numbers                         4: Dashes
                         3: Fixed distance markers
                         2: Touchdown markers
                         1: Threshold markers
                         0: Edges
14        1    Runway colour (repeated in each nibble)
15        1    Edge colour               (")
16        1    Threshold mkr colour      (")17        1    Touchdown mkr colour      (")
18        1    Fixed distance mkr colour (")
19        1    Dash colour               (")
20        1    Number colour             (")
21        1    Runway number (down side) as hex number
22        1    Designator:
                         0: none
                         1: LEFT/RIGHT                         2: RIGHT/LEFT
                         3: CENTER/CENTER
23        1    Down side lights:
               bit       0: End light
                         1: always 0?
                         2: REIL
                         3: VASI
               high nibble value:                         0: none
                         1: MASLR
                         2: MASLR with strobes
                         3: SSALR
                         4: SSALR with strobes
                         5: MALSF
                         6: MALSF with strobes
                         7: SSALF                         8: SSALF with strobes
                         9: ALSF-I
                         A: ALSF-II
24        2    Down side VASI slope in 1/10°
26        1    Up side lights (as in byte 23)
27        2    Up side VASI slope in 1/10°
29        2    Up side direction in 1/182.04°
31        2    Runway width in m33        2    Runway length in m

Note: up side refers to the runway end located up when placing it, down side
is the other end.

Example:

3E 3A 00 2B F9 2D 05 32 00 3E 0E 00 2B F9 2D 0515 00 25 EF 02 0F 00 D0 00 4C 2D 05 00 00 00 00
00 21 2B F9 FF 00 88 DD 88 99 FF FF 04 00 01 1C
00 39 1E 00 5C 15 2D 00 52 08

is interpreted as:

3Eh       Area record
  003Ah        object is 58 bytes long  F92Bh        N coord is [F92Bh =] 63787 - 49152 = 14635
  052Dh        E coord is [052Dh =]  1325 + 16384 = 17709
  0032h        area radius is 50 FSu (12.8 Km)
3Eh       Area record
  000Eh        16 bytes
  F92Bh        N coord is 14635 again
  052Dh        E coord is 17709 again
  0015h        inner area radius is 21 FSu (5.4 Km)25h       Set var
  02EFh        at 02EFh (area altitude)
  000Fh        to 15 m above sea level
D0h       Runway record
  052D4C00h    E coord. of runway is 17709.2969
  00000000h    Altitude is 0
  F92B2100h    N coord. of runway is 14635.8711
  FFh          runway has all design elements  00h          runway colour is Black
  88h          edge colour is Brown
  DDh          threshold mkr colour is Gold
  88h          touchdown mkr colour is Brown
  99h          fix. dist.mkr colour is Yellow
  FFh          dash colour is White
  FFh          number colour is White
  04h          runway number is 4  00h          no designator
  01h          down side has end lights
  001Ch        down side VASI slope is [1Ch =] 28 / 10 = 2.8° *
  39h          up side has VASI and end light (9) of type SSALR (3)
  001Eh        up side VASI slope is [1Eh =] 30 / 10 = 3.0°
  155Ch        runway direction is [155Ch =] 5468 / 182.04 = 30.04°
  002Dh        runway is [002Dh =] 45 meter wide
  0852h        runway is [0852h =] 2130 meter long
Note: down side VASI slope is actually undefined because down side has no
VASI.

====================

MOUNTAINS
Mountains are among the most complex ASD objects.  These are the records used
to define a mountain:

∙ an area record,
∙ a jump over jump record (0Eh) (variable structure construct)
∙ a 3-byte jump record (0Bh) spanning the entire mountain definition
∙ a ref. point record.
Then, for each peak and each point of the base, there is:
∙ a 3D-point record (31h)

∙ a 25h 031Eh 0000h constant record
∙ a 22h record with a byte offset of 001Ah and checking values of vars at
029Ch (E coord.), 029Eh (A coord.), and 02A0h (N coord.)
∙ a 25h 031Eh 0001h constant record
Then, for each side of the mountain, two records are given:
∙ an area colour record (25h 02E2h xxxxh)
∙ a 3D-triangle record (5Ah)

The side list is terminated by the single byte record 51h, and the entire
object by the single byte record 19h

Example:This example describes a square mountain, with sides 2 FSu long and parallel
to the coordinate axes.

3E 00A2 0393 048C 0040   Center: 17299, 17548; radius: 64 FSu
8E 0006                  Jump over the next 0Bh record (var. struct. constr.)
0B 0096                  Jump over [0096h =] 150 bytes
24 04 048C0000 00000000 03930000
                         Ref. point: 17548 E, 0 AGL, 17299 N31 01 0080 0098 0080     1st peak: +0.5 E,+152 m, +0.5 N from ref. point
31 21 FF00 0000 0100     1st point:-1.0 E, + 0 m, +1.0 N from ref. point
31 22 0100 0000 0100     2nd point:+1.0 E, + 0 m, +1.0 N from ref. point
31 23 0100 0000 FF00     3rd point:+1.0 E, + 0 m, -1.0 N from ref. point
31 24 FF00 0000 FF00     4th point:-1.0 E, + 0 m, -1.0 N from ref. point
25 031E 0000             Set var at 031Eh to 0 (fixed)
22 001A                  3-var record: byte offset 26
  029C FF00 0100         var 029Ch (E range): -1.0 to +1.0 around ref. point  029E 0000 0198         var 029Eh (A range): 0 to [0198h - 0100h =] 152 m
  02A0 FF00 0100         var 02A0h (N range): -1.0 to +1.0 around ref. point
25 031E 0001             set var at 031Eh to 1 (fixed)
25 02E2 5555             Surface colour: Light Grey
5A 1300 D000 0000 01 21 24    Triangle thru 1st peak, 1st and 4th points
25 02E2 8888             Surface colour: Brown
5A 0000 D000 1300 01 24 23    Triangle thru 1st peak, 4th and 3rd points
25 02E2 AAAA             Surface colour: Dark Grey5A DA00 E000 0000 01 23 22    Triangle thru 1st peak, 3rd and 2nd points
25 02E2 5555             Surface colour: Light Grey
5A 0000 E000 DA00 01 22 21    Triangle thru 1st peak, 2nd and 1st points
51                       End of triangle list
19                       End of variable structure

====================
TIMING GATES

Timing gate description is not fully deciphered. It is made of:
∙ an area record
∙ a jump over jump record (variable structure construct)
∙ a jump record
∙ a reference point record
∙ an orientation record∙ a single byte record (17h)
∙ a specialized timing gate record
∙ an end of structure record.

-- 53h 3Dh --------- Timing gate (17 bytes)

0         0    53h: object record code
1         1    3Dh: timing gate sub-code2         2    gate width in m
4         2    gate height in m
6         1    front colour (code in both nibbles)
7         1    back colour (code in both nibbles)
8         2    always 0 ??
10        1    gate number from 0 onward; last gate number has msb set
11        2    ??
13        2    ??15        2    ??

Note: the last 3 field values vary from gate to gate of the same amounts of
which E coord., alt. and N coord. vary; they are perhaps connected with the
distance from gate to gate.

====================
BUILDINGS

All real buildings share the same structure (poles, bridges, trees, autos,
fuel boxes and thermal generators depart somewhat from this structure):

∙ an area record
∙ a jump over jump record (0Eh) (variable structure construct)
∙ a 5-byte jump record (0Bh) spanning the entire object definition; the last  word contains a value related to building type and detailed below
∙ a reference point record
∙ an orientation record
∙ a first end of structure record (19h single byte)
∙ a 53h variable record depending on the object
∙ a second end of structure record.

For buildings, the 53h record contains:∙ the record code 53h in the 1st byte
∙ a sub-code related to the building type in the 2nd byte
∙ a series of 2-bytes fields defining wall distances from ref. point (first
  horizontal positions from left [negative] to right [positive], then
  vertical positions from top [positive] to bottom [negative])
∙ a 2-bytes field with base height
∙ a single byte field with peak height (0 for flat roofs)
∙ a series of single byte fields with wall colours and roof pitches colours  (just one if the roof is flat).

All distances are in meters, and colour codes are repeated in both nibbles.

In the following sketches, for each kind of building, code and sub-code of
53h record as well as the build. type in the last word of the jump record are
given; numbers and letters show the order in which wall positions and colour
codes respectively appear within the 53h record.
Rectangular building (53h 01h)
  flat roof (type 0003h)     peaked roof (type 0005h)

  1           2              1           2
  │     a     │              │     a     │
  ┌───────────┐─ 3           ┌───────────┐─ 3
  │           │              │     f     │d │     e     │ b          d ├───────────┤ b
  │           │              │     g     │
  └───────────┘─ 4           └───────────┘─ 4
        c                          c

L building (53h 02h)
  flat roof (type 0007h)     peaked roof (type 0009h)
  1       2      3             1       2      3
  │   a   │      │             │   a   │      │
  ┌───────┐       ─ 4          ┌───┬───┐       ─ 4
  │       │b                   │   │   │ b
  │       │   c                │   │ h │   c
  │       └──────┐─ 5          │ g │  /└──────┐─ 5
f │      g       │           f │   │/    i    │
  │              │ d           │  /└──────────┤ d  │              │             │/      l      │
  └──────────────┘─ 6          └──────────────┘─ 6
         e                            e

Reversed L building (53h 06h)
  flat roof (type 000Bh)     peaked roof (type 000Dh)

  1       2      3             1       2       3  │       │   c  │             │       │   c   │
          ┌──────┐─ 4                  ┌───┬───┐─ 4
        b │      │                   b │   │   │
      a   │      │                 a   │ h │   │
  ┌───────┘      │─ 5          ┌───────┘\  │ g │─ 5
  │         g    │ d           │     i    \│   │ d
f │              │           f ├───────────┘\  │
  │              │             │       j      \│  └──────────────┘─ 6          └───────────────┘─ 6
         e                            e

T building (53h 03h)
  flat roof (type 000Fh)          peaked roof (type 0011h)

  1       2       3       4       1       2       3       4
  │       │   a   │       │       │       │   a   │       │  ┌───────────────────────┐─ 5    ┌───────────────────────┐─ 5
  │                       │       │           i           │
h │                       │ b   h ├───────────┬───────────┤ b
  │           i           │       │     j    /│\    m     │
  └───────┐       ┌───────┘─ 6    └───────┐/  │  \┌───────┘─ 6
      g   │       │    c              g   │   │   │    c
        f │       │ d                   f │ k │ l │ d
          │       │                       │   │   │          └───────┘        ─ 7            └───┴───┘        ─ 7
              e                               e

U building (53h 04h)
  flat roof (type 0013h)          peaked roof (type 0015h)

  1       2       3       4       1       2       3       4
  │   a   │       │   e   │       │   a   │       │   e   │  ┌───────┐       ┌───────┐─ 5    ┌───┬───┐       ┌───┬───┐─ 5
  │       │b     d│       │       │   │   │b     d│   │   │
  │       │   c   │       │       │   │ j │   c   │ m │   │
h │       └───────┘       │─ 6  h │ i │  /└───────┘\  │ n │─ 6
  │                       │ f     │   │/      k      \│   │ f
  │           i           │       │  /└───────────────┘\  │
  │                       │       │/          l          \│
  └───────────────────────┘─ 7    └───────────────────────┘─ 7              g                               g

H building (53h 05h)
  flat roof (type 0017h)          peaked roof (type 0019h)

  1       2       3       4       1       2       3       4
  │   a   │       │   e   │       │   a   │       │   e   │
  ┌───────┐       ┌───────┐─ 5    ┌───┬───┐       ┌───┬───┐─ 5  │       │b     d│       │       │   │   │b     d│   │   │
  │       │   c   │       │       │   │ n │   c   │ r │   │
  │       └───────┘       │─ 6    │   │  /└───────┘\  │   │─ 6
  │                       │       │   │/      p      \│   │
l │           m           │ f   l │ m ├───────────────┤ t │ f
  │                       │       │   │\      q      /│   │
  │       ┌───────┐       │─ 7    │   │  \┌───────┐/  │   │─ 7
  │       │   i   │       │       │   │ o │   i   │ s │   │  │       │j     h│       │       │   │   │j     h│   │   │
  └───────┘       └───────┘─ 8    └───┴───┘       └───┴───┘─ 8
      k               g              k                g

Example of a peaked L building:

3E 0045 0391 048C 0003        Area record
8E 0008 0B 0039 0009          Jump over next jump record0B 0039 0009                  Jump over 57 bytes, object type is 9
24 04 048C0A00 00000000 03918700
                              Ref. point record (center of the object)
16 0000 0000 FC6E 000A        Orient. record: 0° pitch, 0° bank,
                              [FC6E =] -914 / 182.04 = -5.02°
19
53 02                         L building record
  FFF6 FFFF 000A              Ascisses of walls are -10, -1, 10  0007 0001 FFF9              Ordinates of walls are 7, 1, -7
  0004 02                     base heigh is 4 m, peak height is 2 m
  66 88 99 66 88 99           wall colours are L.Blue, Brown, Yellow, L.Blue,
                              Brown, Yellow
  55 AA 55 AA                 roof colours are L.Grey, D.Grey, L.Grey, D.Grey
19

Multi-sided building (53h 4Ch)
  flat roof (type 001Bh) and peaked roof (type 001D) have the same contents:

0         1    53h: record code
1         1    4Ch: record sub-code
2         1    number of sides
3         2    length in m
5         2    width in m7         2    height in m
9         2    two alternating colours for sides
11        2    two alternating colours for roof pitches
12        1    peak height in m

Control tower (type 001Fh; codes 53h 07h)

0         1    53h: record code1         1    07h: record sub-code
2         8    four wall positions as for rectangular buildings
10        2    base height
12        2    always 0Ah ?? (irrelevant)
14        4    four side colours as for rectangular buildings
18        1    roof colour
19        1    always 00h ?? (irrelevant)
Bridge (type 0025h; codes 53h 34h):

0         1    53h: record code
1         1    34h: record sub-code
2         2    length
4         2    width
6         1    suspension colour (0 for non-suspended bridge)
7         1    bridge colour

The following 4 object types lack the orientation record.

Tower (type 0020h; codes 53h 29h) and wind sock (type 0022h; codes 53h 2Eh)
have the same structure:

0         1    53h: record code1         2    29h / 2Eh: record sub-code
2         1    always 0 ?? (irrelevant)
3         2    height

Coniferous (type 0028h; codes 53h 42h) and deciduous tree (type 002Bh; codes
53h 43h) have the same structure:

0         1    53h: record code1         1    42h / 43h: record sub-code
2         1    total height
3         1    width
4         1    trunk height
5         1    leave colour
6         1    trunk colour

Suspended bridges (type 0027h; codes 53h 33h) and autos (type 002Dh; codes53h 47h) add a 28h 36h record right before the 53h record.

Suspended bridges have the same 53h record as standard bridges (of course,
sub-code is 33h instead of 34h).

Autos have a 3-byte 53h record containing, after code and sub-code, only a
byte with the auto colour.
--------------------

Fuel box (type 002Fh).

Fuel box descriptions are complex, but the great part is fixed because fuel
boxes have a fixed size and are always oriented toward the North. Below a
template is given:
3E 0076 xxxx xxxx 0007        Area record (coords may vary, length [118
                              bytes] and radius [7 FSu=ca 1 NM] are constant)
8E 0008                       Jump over next jump (var. struct. construct)
0B 006A 002F                  Jump over 106 bytes; object type 2Fh
24 02 xxxxxxxx xxxxxxxx xxxxxxxx
                              Ref. point record (coords and alt. may vary)
16 0000 0000 0000 000A        Orientation is always flat and North
1928 36 004C 034E FFFF          other 004Ch bytes of description
12 99                         yellow line
40 FF80 FF44                  the "F", described with normal lines
41 FF80 0098                      leg
41 0080 0098                      upper arm
40 007A FFF4                      jump to
41 FF80 FFF4                      lower arm
40 FEFB FEFB                  the box41 00F9 FEFB                      lower side
41 00F9 0101                      right side
41 FEFB 0101                      upper side
29                            close the box
21 0014                       2-var record: byte offset is 20
  029C FEFB 00FF                  var 029Ch (E range) from -260 to 255
  02A0 FEFB 0101                  var 02A0h (N range) from -260 to 257
25 0288 0001                  This is a fuel box19                            End of variable structure

--------------------

Thermal generator (type 0031h)

Thermal generators also have a very special description including some
general records. Again, a template is given.
3E 006A xxxx xxxx xxxx        Area record (106 bytes long, coords may vary,
                              as well as radius, which depend on size)
8E 0008                       Jump over next jump record (var. struct. con.)
0B 005E 0031                  Jump over 94 bytes; object type is 0031
24 04 xxxxxxxx xxxxxxxx xxxxxxxx
                              Ref. point record
16 xxxx xxxx xxxx 000A        Orientation record19
25 02E2 xxxx                  Surface colour record
2F                            Polygon begin
40 xxxx xxxx                  generator area as a polygon
41 xxxx xxxx
41 xxxx xxxx
41 xxxx xxxx
29                            close area and fill45 0025                       a 45h record, 0025h bytes long, follow:
    xxxxxxxx                  E coord of generator center
    ????????                  ??? (4 bytes)
    xxxxxxxx                  N coord of generator center
    xxxx                      orientation
    ??                        ??? (1 byte)
    xxxx                      generator width (in m)
    ????                      ??? (2 bytes)    xxxx                      thermal effect height (in feet)
    ????                      ??? (2 bytes)
    xxxx                      generator length
    ??????????????????        ??? (9 bytes)

========================================


                          DYNAMIC SCENERIES (.DY1)


GENERAL STRUCTURE

Dynamic scenery files are made of:
∙ a header containing various pointers∙ a pattern definition section containing the definitions of all the patterns
in the file
∙ a pattern code section containing the actual description of the patterns.

====================

HEADER STRUCTURE; length: 43 bytes
0         2    file length
2         2    0002h (a kind of signature?)
4         2    000Ch (= 12; pointer to scenery name)
6         2    002Bh (= 43; header length)
8         2    number to be assigned to the next pattern that will be defined
10        2    pointer to pattern code section
12        31   scenery names: up to 30 characters (padded with space, if
               shorter) plus a 0 ending byte
====================

PATTERN DEFINITION SECTION

The pattern definition section contains a 48-byte block for each pattern of
the scenery.
0         2    pattern number (see note)
2         2    model:    0065h  Cessna R182
                         0066h  Boeing 747
                         0067h  Gates Learjet
                         0068h  F14
                         0069h  Schweizer SGS
                         012Dh  Fuel truck
                         0137h  Red car                         0138h  Blue car
                         0139h  White car
                         0191h  Sail boat
               Any other model code is rendered by ASD as a Cessna R182.
4         2    pointer to the corresponding pattern code
6         2    length of the corresponding pattern code
8         2    number of the pattern after which this pattern will start,
               zero if patter starts immediately10        1    begin code:
                         0    immediately
                         1    after other pattern starts
                         2    after other pattern takes off
                         3    after other pattern lands
                         4    after other pattern parks
11        1    status code: 0 - inactive, 1 - active
12        1    end action code:                         0    start over
                         1    park
                         2    disappear
13        1    display before start: 0 - yes, 1 - no (sic!!)
14        4    ??? (irrelevant)
18        30   pattern name, padded with spaces, no ending zero

Note: to each new pattern is assigned the number contained at byte 8 of fileheader which is then increased; when a pattern is deleted, its record is
removed and other patterns are shifted but its number is not made available,
nor other pattern numbers are modified to fill a possible gap, as a
consequence patterns can have numbers greater than the total number of
patterns present in the file.

====================
PATTERN CODE SECTION

This section contains all the definitions of the scenery patterns, one after
the other. Pattern definitions are made of 5 kinds of records:
00h       Initial record      20 bytes
FFh       Position record     21 bytes
02h       Look record         5 bytes
06h       Take off/Land record 2 bytes04h       End of pattern record 1 byte

-- 00h ------------- Initial record (20 bytes)

Used to set the initial position of the object at the beginning of the
pattern.

1         4    E coord (fract. FSu; all 4 bytes used)5         4    alt. AGL (fract. FSu; all 4 bytes used)
9         4    N coord (fract. FSu; all 4 bytes used)
13        2    pitch (noze down is positive, noze up is negative)
15        2    bank (left is positive, right is negative)
17        2    heading
19        1    always 03 ??

Note: Pitch variation is somewhat special: if the object rotates more than90° up or down, it is reversed up side down and pitch sign is changed!

-- 02h ------------- Look record (5 bytes)

Look record defines some visual detail of the object. To my knowledge, a look
record may have 3 sub-codes, related to 3 visual aspect; patterns always
begin defining the initial values of these aspects with 3 look records, one
for each sub-code.
1         2    FFFEh:    shadow is visible or not
               FFFDh:    object is flying or landed
               FFFBh:    gear is lowered or not
3         2    value:    for FFFEh: 1 = shadow on, 0 = shadow off
                         for FFFDh: 2 = landed, 0 = flying
                         for FFFBh: 4 = gear down, any other value = up
Notes: Shadow is switched off by ASD when the object raises above ca. 100 m
from ground level. Sub-code FFFDh probably triggers patterns starting after
another pattern's landing or taking off.

-- 04h ------------- End of pattern (1 byte)
End of pattern record

Used to mark the end of a pattern. It is made of the single byte 04h.
-- 06h ------------- Teake off/land record (2 bytes)

A take off (land) record is inserted after the movement that caused the model
to rise over (to sink at) the ground level. Each of them is always followed
by the corresponding 02h FFFDh record.

1         1    02h: take off (always followed by a 02 FFFD 0000 record)               03h: landing (always followed by a 02 FFFD 0002 record)

-- FFh ------------- Position record (21 bytes)

Position record is identical to initial record, excepted the record code and
the last field. It is used through the entire pattern description to mark
successive positions and orientations of the object.
1         4    E coord  (fract. FSu)
5         4    alt. AGL (fract. FSu)
9         4    N coord  (fract. FSu)
13        2    pitch (noze down is positive, noze up is negative)
15        2    bank (left is positive, right is negative)
17        2    direction
19        2    time between the previous (or initial) position and this one
Note: The time interval between positions is apparently measured in ticks, 1
tick every 0.008 sec (or 126 ticks per sec). Time intervals are not constant
but shorter when the position (or orientation) variation is greater and
longer when it is smaller. It seems never to exceed ca 1500 ticks (12 sec).
About other fields, the same observations made for the initial record apply.

====================
Patterns usually begin with:

record 02 FFFE           to define initial conditions
record 02 FFFB                "
record 02 FFFD                "
record 00                to define initial point and orientation

Then enough FFh records follow to define successive positions andorientations of the object. Change in visual aspects and flying condition are
marked by appropriate records. The pattern is closed by the

record 04

========================================

                              DEMO FILES (.DEM)
Demo files, like dynamic sceneries, have a relatively simple structure and
record set. Basically, demo files describe successive positions (and
orientations) of the aircraft with a flow of position records; these records,
however, are intersparsed with single byte codes that correspond to the keys
pressed by the user during demo recording.
Contrarily to dynamic sceneries, aircraft position is sampled at a fixed rate
(either 1 or 5 sec) and all the codes for keys pressed between two samplesare grouped and inserted between the two corresponding position records.

                                  KEY CODES

Key codes correspond, in almost all cases, to the hardware press scan codes
generated by the keyboard and are, therefore, less than 80h.

Some kind of tanslation is, however, carried out by the demo recorder:
∙ on all keyboards, some key codes are ignored and some other are converted
  to 00h
∙ on 101-key keyboards, function keys are converted to their functional
  equivalent of the 83-key keyboard and the corresponding scan code is used
∙ some keys of the numeric pad have the same function in the 101-key keyboard
  (like Gray /, Gray * and ScrollLock, or Gray + and Gray Enter) and their
  scan code are merged∙ scan code prefixes used by 101-key keyboards to differentiate among
  duplicated keys (left and right Alt and Ctrl, white and gray cursor
  keys...) are thrown away.
∙ release scan code are ignored.

Excepted for a few special keys (like Shift, Ctrl and Alt), all key presses
are recorded, even if they do nothing.
Key presses are executed as soon as they are met during demo play back: they
affect the instrument panel, the display and outer world simulation in the
same way as during normal flight; apparently, however they do not affect
flight simulation which is based on the position records. Subsequent position
records are interpolated to simulate a continuous flight.

The following table lists all the key codes generated by the demo recorder
with their corresponding key; function key codes have two corresponding keys,the first is for 83-key keyboards, the second for 101-key keyboards.

All codes are in hex.

Alphanumeric keys

01  Esc       0F  Tab       [1D ∙]        [2A ∙]        [38 ∙]
02  '1'       10  'Q'       1E  'A'       [2B ∙]        39  Space03  '2'       11  'W'       1F  'S'       2C  'Z'       3A  CapsLk
04  '3'       12  'E'       20  'D'       2D  'X'
05  '4'       13  'R'       21  'F'       2E  'C'
06  '5'       14  'T'       22  'G'       2F  'V'
07  '6'       15  'Y'       23  'H'       30  'B'
08  '7'       16  'U'       24  'J'       31  'N'
09  '8'       17  'I'       25  'K'       32  'M'
0A  '9'       18  'O'       26  'L'       33  ','0B  '0'       19  'P'       27  ';'       34  '.'
0C  '-'       1A  '['       28  '''       35  '/'
0D  '+'       1B  ']'       29  '`'       [36 ∙]
0E  BkSp      1C  Enter                   37  '*'-PrtSc

Function keys               Numeric pad keys

3B  F1/F5   3C  F2/F4       45  NumLk   46  Gr /|*|ScrollLk3D  F3/F6   3E  F4/F3       47  Home    48  Up      49  PgUp    4A  Gr -
3F  F5/∙∙   40  F6/∙∙       4B  Left    4C  Pad 5   4D  Right   4E  Gr +|<─┘
41  F7/F7   42  F8/F2       4F  End     50  Down    51  PgDn
43  F9/F8   44  F10/F1      52  Ins     53  Del                 56 '<'∙∙∙

Notes:
∙   Scan codes 1D, 2A, 2B, 36, 38 would correspond to Ctrl, Left Shift, '\',
Right Shift, Alt respectively; but within demos, Shift and '\' keys do notgenerate any code, while Ctrl and Alt keys generate a 00 code.

∙∙  No F key of 101-key keyboard correspond to F5 and F6 of 83-key keyboard:
therefore those codes are never recorded with a 101-key keyboard

∙∙∙ Code 56 is generated (and recorded) only with 102-key European keyboards.

                                   RECORDS
All records have a code >= 80h and are therefore easily differentiated from
key codes.

Only 8 kinds of records have been recognized and are listed below. The first
four of them are actually found in demo files generated by the demo recorder;
the other four have been found in the demo supplied with the program (the
default demo as well as the instructor flights of the flight school and thelead plane flights of the formation entertainement which are all regular demo
files), but are correctly played back if manually inserted in a recorded
demo.

A recorded demo has a very simple structure: it is made of sample rate
records (either 80h or 81h) followed by long position records; between a
position record and the next sample rate record, the codes for key pressed by
the user are inserted. The file is not divided in sections (like, forinstance, scenery files) nor its end is marked in any way.

-- 80h ------------- 1 sec (1 byte)

This single byte record marks a sample rate of 1 sec and is usually followed
by a long position record.

-- 81h ------------- 5 sec (1 byte)
This single byte record marks a sample rate of 5 sec and is usually followed
by a long position record.

-- 82h ------------- Long position record (19 bytes)

1         4    E coord. (fract. FSu)
5         4    Alt. AGL (fract. FSu)9         4    N coord. (fract. FSu)
13        2    pitch (noze down is positive, noze up is negative)
15        2    bank (left is positive, right is negative)
17        2    heading

This record is usually preceded by a 1 sec or a 5 sec record.

--84h -------------- Message (mess.length+2 bytes)
1         xx   Message text
1+xx      1    00h

====================

Supplied demos contain four more kinds of record, allowing for adding a major
feature (mode record) and for saving some bytes.
They usually begin with a mode record which sets the initial conditions; a 1
sec position record follows giving the aircraft initial position, then a flow
of short position records describes subsequent aircraft positions. As usual,
key codes are inserted among position records to interact with the simulator.

-- 8Ah ------------- Mode record (528 bytes)
1         526  Mode
527       1    8Bh: end of mode

This record embeds a full mode, with exactly the same structure of a .MOD
mode file; this allows specifying all the display, environment and flight
conditions within a demo.  Mode records are usually inserted at the beginnig
of a demo to prepare the field; other mode records can however appear
anywhere in a .DEM to change simulation parameters.
-- 90h ------------- 1 sec/position (19 bytes)

1         4    E coord. (fract. FSu)
5         4    Alt. AGL (fract. FSu)
9         4    N coord. (fract. FSu)
13        2    pitch (noze down is positive, noze up is negative)
15        2    bank (left is positive, right is negative)17        2    heading

This record has the same structure of the 82h record, but contains also a 1
sec sample rate information.

-- 91h ------------- 5 sec/position (19 bytes)

1         4    E coord. (fract. FSu)5         4    Alt. AGL (fract. FSu)
9         4    N coord. (fract. FSu)
13        2    pitch (noze down is positive, noze up is negative)
15        2    bank (left is positive, right is negative)
17        2    heading

This record has the same structure of the 82h record, but contains also a 5
sec sample rate information.
-- 94h ------------- Short position record (7 bytes)

This record describes the variations of the 6 position parameters relatives
to a previous position record (either a 90h record or another 94h record). It
can be used also after an 82h record, even if MS demos never do so.
The record includes also 1 sec of sample rate.
1         1    E coord. delta
2         1    Alt. delta
3         1    N coord. delta
4         1    Pitch delta
5         1    Bank delta
6         1    Heading delta

Linear parameters are in m, angular parameters in 1.4° (= 360° / 256); all 6parameters are signed: the max linear delta is therefore 127 m, and the max
angular delta is 180°.

Short position records save 12 bytes each over long position records.
Apparently, there is no short position record for 5 sec interval.

========================================


                              MODE FILES (.MOD)

Mode files still have many obcure points, but almost all the parameters the
can be set from FS menu are decoded.  Exceptions are mouse sensitivity
parameters, because I do not use a mouse with FS (it seems to me like driving
a car with the foots), and joystick parameters because I do not have one (Iam a serious person, I don't play games!).

There is a lot of undecoded 1-byte fields; they are probably unused and maybe
are only the MSBytes of word fields which never exceed an 8-bit value.

Screen coordinates (for window positions) are apparently device-independent
(I tried on a VGA and a Hercules): ascissae span from 0032h to 1FD6h and
ordinates from 0032h to 17D4h; origin is in the upper left corner.
The following listing follows the same format used above, but, given the
length of the mode "record", a column with hex offset has been added.

Key labels (as <F1>) refer to the 101-key keyboard.


   0 0000   2  020Eh: file length   2 0002   2  0017h: pointer to mode name
   4 0004   1  01h: mode file signature
   5 0005   4  Initial E coord. (fract. FSu)
   9 0009   4  Initial AGL alt. (fract. FSu)
  13 000D   4  Initial N coord. (fract. FSu)
  17 0011   2  Initial pitch
  19 0013   2  Initial bank
  21 0015   2  Initial heading  23 0017  31  Mode name (padded with spaces and 0-terminated)

               FIRST 3D WINDOW
  54 0036   2  Left border position
  56 0038   2  Top border position
  58 003A   2  Width
  60 003C   2  Height
  62 003E   1  View:     00h    Cockpit                         01h    Tower
                         02h    Track
                         03h    Spot plane
  63 003F   1  Cockpit view direction: counterclockwise 00h front -> 07h
               front left
  64 0040   2  Cockpit view zoom:
                         0010h  .16 x
                         0020h  .33 x                         0040h  1 x
                         0081h  2 x
                         0103h  4 x
                         0207h  8 x
                         040Fh  16 x
                         081Fh  32 x
                         103Fh  64 x
                         207Fh  129 x                         40FFh  256 x
                         7FFFh  511 x
  66 0042   2  Tower view zoom (as above)
  68 0044   2  Track view zoom (as above)
  70 0046   2  Spot plane view zoom (as above)
  72 0048   1
  73 0049   1  Spot view direction: counterclockwise 00h front -> E0h front
               left (01h = 1.4°)  74 004A   2  Spot plane distance (in 1/256 m)
  76 004C   2
  78 004E   1  Spot plane preference:  00h roll  -  01h loop
  79 004F   1  Spot plane transition:  00h slow  -  01h fast
  80 0050   2  Spot plane altitude (in 1/256 m)
  82 0052  28  ?? (these bytes change when the cockpit view direction
               changes, but without any clear pattern)
               SECOND 3D WINDOW
 110 006E   2  Left border position
 112 0070   2  Top border position
 114 0072   2  Width
 116 0074   2  Height
 118 0076   1  View:     00h    Cockpit
                         01h    Tower
                         02h    Track                         03h    Spot plane
 119 0077   1  Cockpit view direction: counterclockwise 00h front -> 07h
               front left
 120 0078   2  Cockpit view zoom (see byte 64)
 122 007A   2  Tower view zoom (as above)
 124 007C   2  Track view zoom (as above)
 126 007E   2  Spot plane view zoon (as above)
 128 0080   1 129 0081   1  Spot view direction: counterclockwise 00h front -> E0h front
               left (01h = 1.4°)
 130 0082   2  Spot plane distance (in 1/256 m)
 132 0084   2
 134 0086   1  Spot plane preference:  00h roll  -  01h loop
 135 0087   1  Spot plane transition:  00h slow  -  01h fast
 136 0088   2  Spot plane altitude (in 1/256 m)
 138 008A  28  ?? (these bytes change when the cockpit view direction               changes, but without any clear pattern)

 166 00A6   2  Map window left border position
 168 00A8   2  Map window top border position
 170 00AA   2  Map window width
 172 00AC   2  Map window height
 174 00AE   1  Current window:
                         00h    first 3D                         01h    second 3D
                         02h    map
 175 00AF   1  First 3D:  00h off  -  01h on
 176 00B0   1  Second 3D:  00h off  -  01h on
 177 00B1   1  Map:  00h off  -  01h on
 178 00B2   1  Position indic.:  00h off  -  01h on
 179 00B3   1  Instr. panel:  00h off  -  01h on
 180 00B4   1  Full external view:  00h off  -  01h on 181 00B5   1
 182 00B6   1  Titles on windows:  00h off  -  01h on
 183 00B7   1
 184 00B8   1  Shader:  00h off  -  01h on
 185 00B9   1
 186 00BA   1  Stars:  00h off  -  01h on
 187 00BB   1
 188 00BC   1  Ground text.:  00h off, 01h dots, 02h small rect, 03h big rect 189 00BD   1  Crash:  00h off, 01h detect, 02h detect and analyse
 190 00BE   1  Sound:  00h off  -  01h on
 191 00BF   1  Pause:  00h off  -  01h on
 192 00C0   1  Realism, bits (realism scale is at offset 299):
                         0      engine
                         1      elevator trim
                         2      gyro drift
                         3      light burn                         4      fast throttle
                         5      instrument lights
                         6      barometer drift
                         7      [unused]
 193 00C1   1  Axis indicator:
                         00h    none
                         01h    V-shaped
                         02h    4-dots                         03h    small V
 194 00C2   1  Auto coordination:  00h off  -  01h on
 195 00C3   1
 196 00C4   1  Smoke system:  00h off  -  01h on
 197 00C5   1
 198 00C6   1  ATC comm:  00h off  -  01h 0n
 199 00C7   1
 200 00C8   1  Slew:  00h off  -  01h on 201 00C9   3  ??
 204 00CB   2  Rotat. slew: negative = right, positive = left (+- 80h each
               <End> or <PgDn>)
 206 00CE   1
 207 00CF   1  Altit. slew:  00h max up -> 40h stable -> 7Fh max down (+- 02h
               each <A> or <Q>, <F1> -> 7Fh, <F4> -> 00h)
 208 00D0   1
 209 00D1   1  Longit. slew: negative = forward, positive = rear (+-01h each               <Down> or <Up>)
 210 00D2   1
 211 00D3   1  Side slew: negative = left, positive = right (+-01h each
               <Right> or <Left>)
 212 00D4   2  ??
 214 00D6   1  EFIS/CFPD:  00h off  -  01h on (equal to byte 394)
 215 00D7   3  ??
 218 00DA   3  Hours, min and sec as hex numbers 221 00DD  12  ??
               Instrument panel display (instr. displayed when bit set):
 233 00E9   1  bits:     0      airspeed
                         1      turn coordination
                         2      gyro heading
                         3      altimeter
                         4      attitude
                         5      VOR 1                         6      tacheometer
                         7      vertical velocity
 234 00EA   1  bits:     0      time
                         1      transponder
                         2      NAV 1
                         3      COM
                         4      compass
                         5      fuel                         6      oil
                         7      AUX 2
 235 00EB   1  bits:     0      gear and carb heat
                         1      NAV 2
                         2      DME
                         3      VOR 2
                         4      ADF
                         5      AUX 1                         6      AUX 4
                         7      AUX 3
 236 00EC   5  ??

               WINDS
 241 00F1   1  Layer 3 speed (in kt)
 242 00F2   1  Layer 3 turbulence:  00h -> 0Ah
 243 00F3   2  Layer 3 direction (in 1/182.04°) 245 00F5   1  Layer 2 speed (in kt)
 246 00F6   1  Layer 2 turbulence:  00h -> 0Ah
 247 00F7   2  Layer 2 direction (in 1/182.04°)
 249 00F9   1  Layer 1 speed (in kt)
 250 00FA   1  Layer 1 turbulence:  00h -> 0Ah
 251 00FB   2  Layer 1 direction (in 1/182.04°)
 253 00FD   1  Surface speed (in kt)
 254 00FE   1  Surface turbulence:  00h -> 0Ah 255 00FF   2  Surface direction (in 1/182.04°)
 257 0101   2  Layer 3 tops (in m)
 259 0103   2  Layer 3 base (in m)
 261 0105   2  Layer 2 tops (in m)
 263 0107   2  Layer 2 base (in m)
 265 0109   2  Layer 1 tops (in m)
 267 010B   2  Layer 1 base (in m)
 269 010D   2  Surface depth (in m)
               CLOUDS
 271 010F   2  Top layer tops (in m)
 273 0111   2  Top layer base (in m)
 275 0113   2  Top layer coverage:  00h clear  ->  08h overcast
 277 0115   2  Top layer deviation (in m)
 279 0117   2  Bottom layer tops (in m)
 281 0119   2  Bottom layer base (in m) 283 011B   2  Bottom layer coverage:  00h clear  ->  08h overcast
 285 001D   2  Bottom layer deviation (in m)
 287 011F   2  Thunderstrom tops (in m)
 289 0121   2  Thunderstorm base (in m)
 291 0123   2  Thunderstorm coverage:  00h widely scatt.  ->  02h dense
 293 0125   2  Thunderstorm speed (in 1/2 kt)
 295 0127   2  Thunderstorm direction (in 1/182.04°)
 297 0129   1  Reliability:  00h  ->  64h 298 012A   1
 299 012B   1  Realism:  00h  ->  64h
 300 012C   1
 301 012D  26  ?? this portion contains mouse and joystick parameters
 327 0147   1  Keyboard aileron sensibility:  01h = 1 -> 7Fh = 8
 328 0148   1
 329 0149   1  Keyboard elevator sensibility:  01h = 1 -> 7Fh = 8
 330 014A   1 331 014B   1  Keyboard rudder sensibility:  01h = 1 -> 7Fh = 8
 332 014C   3  ??
 335 014F   2  Panel instrument top border
 337 0151   2  ??
 339 0153   1  Season:  00h winter -> 03h autumn
 341 0155   6  COM freq as ASCII string of the form "120;30"
 347 015B   1  always 0 ??
 348 015C   1  NAV1 active:  00h off  -  01h on 349 015D   6  NAV1 freq as ASCII string of the form "120;30"
 355 0163   1  always 0 ??
 356 0164   1  NAV2 active:  00h off  -  01h on
 357 0165   6  NAV2 freq as ASCII string of the form "120;30"
 363 016B   3  OBI1 inbound course as ASCII string of the form "120"
 366 016E   1  always 0 ??
 367 016F   1  VOR1 active:  00h off  -  01h on
 368 0170   3  OBI1 outbound course as ASCII string of the form "120" 371 0173   1  always 0 ??
 372 0174   1  VOR2 active:  00h off  -  01h on
 373 0175   3  OBI2 inbound course as ASCII string of the form "120"
 376 0178   1  always 0 ??
 377 0179   1  VOR2 active:  00h off  -  01h on
 378 017A   3  OBI2 outbound course as ASCII string of the form "120"
 381 017D   1  always 0 ??
 382 017E   1  Transponder active:  00h off  -  01h on 383 017F   4  Transponder freq as ASCII string of the form "1200"
 387 0183   1  always 0 ??
 388 0184   1  ADF active:  00h off  -  01h on
 389 0185   3  ADF freq as ASCII string of the form "120"
 392 0188   1  EFID/CFPD function:
                         00h    none
                         01h    lock to ILS for landing approach
                         02h    lock to navaid and alt. tracking 393 0189
 394 018A   1  EFIS/CFPD:  00h off  -  01h on (equal to byte 214)
 395 018B   1
 396 018E   1  EFIS/CFPD type:  00h rect,  01h bricks,  02h poles
 397 018F   1
 398 0190   1  EFIS/CFPD density:  00h thick,  01h medium,  02h thin
 399 0191   1
 400 0192   1  EFIS/CFPD range:  00h short,  01h medium,  02h long 401 0193   1
 402 0194   1  EFIS/CFPD navaid:  00h NAV1,  01h NAV2
 403 0195   1
 404 0196   2  EFIS/CFPD tracking altitude (in m)
 406 0198  66  ???? (this portion apparently contains, among other things,
               the dynamic parameters (velocity vector, angular
               velocities...), but no clear relation has emerged)
 472 01D8   1  Elevator 'carry':  01h when full pushed, FFh when full pulled,               00h otherwise
 473 01D8   1  Elevator:  C0h full pushed -> 3F full pulled; +-01h each
               <Down> or <Up>
 474 01D9   1  Aileron 'carry':  01h when at full left, FFh when at full
               right, 00h otherwise
 475 01DA   1  Ailerons:  C0h full left -> 3Fh full right; +- 04h each
               <Rigth> or <Left>
 476 01DB   1  Rudder 'carry':  01h when at full left, FFh when at full               right, 00h otherwise
 477 01DC   1  Rudder:  C0h full left -> 3Fh full right; +- 04h each <Rigth>
               or <Left>
 478 01DE   1  Throttle 'carry':  FFh when full, 00h otherwise
 479 01DF   1  Throttle:  00h cut -> 3Fh full; +-02h each <PgUp> or <PgDn>
 480 01E0   1  Trim 'carry':  01h when full down, FFh when full up, 00h
               otherwise
 481 01E1   1  Trim:  C0h full down -> 3F full up; +-01h each <End> or <Home> 482 01E2  10  ??
 492 01EC   2  Position indic. window left border
 494 01EE   2  Position indic. window top border
 496 01F0   4  Tower E coord (fract FSu)
 500 01F4   4  Tower AGL alt (fract FSu)
 504 01F8   4  Tower N coord (fract FSu)
 508 01FC   2  ??
 510 01FE   1  Flap 'carry':  FFh when flap down, 00h otherwise 511 01FF   1  Flap:     00h    0°
                         20h    10°
                         40h    20°
                         60h    30°
                         7Fh    40°
 512 0200   1  Gear:  00h up  -  FFh down
 513 0201   1  Lights:  00h off  -  FFh on
 514 0202   1  Mags:     00h    off                         01h    left
                         02h    right
                         03h    both
                         04h    start
                         05h    lean
 515 0203   1
 516 0204   1  Carb heat:  00h off  -  FFh on
 517 0205   1  Strobe:  00h off  -  01h on 518 0206   8  .SIM file name. .SIM files define the visual appearance of the
               aircraft; the name is padded with space if shorter than 8
               chars. No path nor extension are allowed (a standard .SIM
               extension is apparently supplied by the program)
                         FS4 .SIMs:
               SIM1.SIM         Cessna R182
               SIM2.SIM         Gates Learjet 25G
               SIM3.SIM         Schweizer 2-32 Sailplane               SIM4.SIM         Sopwith Camel
               SIM5.SIM         Experimental aircraft
                         ASD .SIMs:
               SIM7.SIM         Experimental jet aircraft
               SIM8.SIM         Experimental sailplane
               SIM9.SIM         Boeing 747-400
               SIMA.SIM         Beechcraft Starship
               SIMB.SIM         Piper Cherokee Archer II               SIMC.SIM         Cessna 182 seaplane

========================================



               APPENDIX: A NOTE ON F1 (DEFAULT SCENERY) HEADER
The following note is a first step in attempting to decode the default
scenery F1 supplied with FS.  Only the initial file header is covered.  It
has been checked with sceneries supplied with FS veriosn 4.0 and 4.0b.  They
are different, but perhaps only marginally and, in any case, not in the
portion covered here.

0000h     2    02DDh: ??
0002h     2    0106h: pointer to dialogue descriptor (see below)0004h     28   ??
0020h     2    0026h: number of scenery regions in the file

Then, a table is given with, for each scenery region:

          4    long pointer to region offset in the file
          2    region length in bytes
Table ends at 0106h. A descriptor of the dialogue window displayed when the
scenery is selected follows:

0106h     1    01h: ??
0107h     2    01F4h: X screen coordinate of text line
0109h     2    0258h: Y screen coordinate of text line
010Bh     25   text line: "Available Flight Areas:" 0-terminated and with
               a 0 byte added at both ends
This is repeated for the 7 text lines up to

0186h     5    00h 3Ch 00h FFh 28h  ??
018Bh     35   two 21h records and one 79h record

After that, the first scenery begins. I sampled them at random and they seems
to be made of the same record machinery (maybe with some new record types) ofother kinds of scenery, but have no header or section tables as .SC1 files
do.  F1, as well as *.SCN, do not use a linked list of 3Eh records, but a
linked list of many kinds of record (21h occurring very often).


==================== FSSTRUCT END ====================